STATUS OF THE CLAIMS 



Claims 1-45 were originally filed in this patent application. In response to the 
first office action, an amendment was filed on 07/17/2007 that cancelled claims 2, 7, 12, 
17-18, 20, 24, 28, 32-33, 35-37 and 42-45, and amended claims 1,6, 11, 16, 19, 23,27, 
31, 34 and 41. In the pending final office action, claims 1, 3-6, 8-11, 13-16, 19, 21-23, 
25-27, 29-31, 34 and 38-41 were rejected under 35 U.S.C. §103(a)as being unpatentable 
over U.S. Patent No. 6,530,078 to Shmid et al. (hereinafter "Shmid"). No claim was 
allowed. No claim has been amended herein. Claims 1, 3-6, 8-11, 13-16, 19, 21-23, 25- 
27, 29-31, 34 and 38-41 are currently pending. 
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REMARKS 



Re jection of claims 1, 3-6, 8-11, 13-16, 19, 21-23, 25-27, 29-31, 34 and 38-41 under 35 
U.S.C. § 103(a) 

In the pending office action the examiner states that claims 2, 7, 12, 18, 20, 24, 
28, 32, 37, and 45 are rejected under 35 U.S.C. § 103(a). These claims were cancelled in 
the amendment in response to the first office action, so the examiner's statement is in 
error. However, the body of the rejection addresses claims 1, 3-6, 8-11, 13-16, 19, 21-23, 
25-27, 29-31, 34 and 38-41. It is therefore assumed that the examiner meant to reject 
claims 1, 3-6, 8-11, 13-16, 19, 21-23, 25-27, 29-31, 34 and 38-41 under 35 U.S.C. 
§ 103(a) as being unpatentable over Shmid. Each of these claims is addressed below. 

Claim 1 

In rejecting claim 1 , the examiner states that Shmid discloses: 

(D2) a virtual dc\ ice drncr in llic second logical partition, wherein 
the \ nlual de\ ice diner pro\ ides a set ol functions al least partially 
determined by function-- a\ ailahle in the I () adapter device driver in the 
first logical partition. 

The language of limitation (D2) recited in the rejection is language that is no 
longer in claim 1 due to the previously-filed amendment. Because the examiner's 
rejection addresses claim language that is no longer in claim 1, the examiner's 
rejection of claim 1 is in error. 

In rejecting the limitations of claim ! . the examiner states. 

It would have been obvious to one of ordinary skill in the art that 
Shmid impliedly teaches the querying of the I/O adapter device to 
determine the available functions. Since the guest is given access to all 
functions available via the host operations system through the virtualized 
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device (Col. 9, lines 4-48), the virtualized device and its driver must have 
access to all functions of the real device in order to make those functions 
available to guest operating systems. 

The examiner makes the assumption that because the virtualized device must have the 
functions of the real device, that the real device must have been queried to obtain those 
functions. This is an erroneous assumption. Nowhere does Shmid teach or suggest 
"querying the I/O adapter device driver in the first logical partition for its available 
functions" as recited in claim 1. For this reason alone, claim 1 is allowable. 

In an attempt to justify the assumption that Shmid impliedly teaches the querying 
of the I/O adapter device to determine its available functions, the examiner states: 

Also, Shmid discloses that the virtual machine (VM), upon which the 
guest operating system runs within the host, is capable of querying for the 
features of a device in the system for the purpose of configuring the VM 
(Col. 36, lines 65-67 and col. 37, lines 20-33). 

The examiner's statement is incorrect. Shmid teaches at col. 37 line 30 "024-query 
device and t\pe features." I here is no explanation in Shmid regarding the locution of the 
device being queried. The examiner assumes without any express teaching in Shmid that 
the querying of device and type features in Shmid reads on querying the I/O adapter 
device driver in the first logical partition for its available functions, which at least 
partially determine a set of functions provided in the virtual device driver in a second 
logical partition. Claim 1 recites interaction between two logical partitions that is not 
accounted for in the examiner's rejection. 

To determine the reasonable scope of the teaching "024-query device and type 
features" in Shmid, we must look to the other teachings in Shmid that provide a context 
that allow inferring what this line means. The Abstract of Shmid states: 

Each guest system is configured such that if a Start Interpretive Execution 
instruction in invoked, the instruction is interpreted and : rr p 1 
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function is performed in its place to simulate, for the guest program or 
operating system, the effect of the IBM S/390 computer architecture. 
Control is then returned to the guest system at the next instruction after the 
Start Interpretive Execution instruction, thus allowing the guest program 
or operating system to execute transparently. 

The goal of Shmid is therefore to create an environment where a guest program or 
operating system in the guest system executes without knowing it is in a virtual machine. 
This is what is meant by "thus allowing the quest program or operating system to execute 
transparently." The presence of the host operating system is hidden from the guest 
operating system or program. For all practical purposes, the guest operating system or 
program thinks it is operating on an IBM S/390 computer system. Because the guest 
operating system or application thinks it is operating on an IBM S/390 computer system, 
there cannot be any special code or information in the guest system that tells the guest 
operating system or application there is a host system inside which the guest system is 
executing in a virtual manner. As a result, the examiner's assumption that a virtual 
device driver in the guest system can query an I/O adapter device driver in the host 
system for its available functions is in error. This would violate the transparency 
expressly taught by Shmid. This would require the guest system have knowledge of the 
host system, which it does not. 

So how does Shmid handle an I/O request from a guest operating system or 
program to a physical I/O adapter? Col. 5 lines 42-49 state: 

When an I/O operation or a special CPU function is requested by the guest 
system the SIE instruction is intercepted and ISX receives control to the 
point just after the SIE instruction. ISX recognizes the reason for the 
interception and performs the corresponding function. If an I/O operation 
is requested with a real I/O device, ISX requests the host operating system 
to execute it using its standard facilities. 

This shows once again that the guest system is oblivious to the fact it is running 
inside a host system. Because the guest system in Shmid has no knowledge it is 
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operating within a host system, the guest system has no direct interaction with the 
host system. Instead, the host system intercepts instructions and simulates them 
for the guest system to make it appear to the guest system the guest system is 
running on an IBM S/390 computer system. This shows conclusively that it is 
impossible for a virtual device driver in a guest system to query an I/O adapter 
device driver in the host system, as suggested by the examiner. 

The examiner correctly states the virtualized device and its driver must 
have access to all functions of the real device in order to make those functions 
available to guest operating systems. However, the examiner's assumption that 
this necessarily means the I/O adapter device driver in the host system is queried 
to determine its functions is not supported in Shmid. To the contrary, the virtual 
walls erected to maintain the appearance of an IBM S/390 computer system from 
the guest system perspective do not allow a virtual device driver in the guest 
system to query an I/O adapter device driver in the host system. For this reason, 
the examiner's assumption is in error. 

Applicant in the previous amendment provided many different ways the 
guest system could be made aware of all of the functions of the I/O adapter device 
driver without violating the virtual separation between the guest system and the 
host system. For example, let's assume an I/O adapter device driver in the host 
includes functions A, B, C and D. The examiner assumes this necessarily means 
the I/O adapter device driver must be queried to determine these functions. 
However, there are many possibilities other than querying the I/O adapter device 
driver. For example, a programmer could look at a specification sheet for the VO 
adapter device driver that indicates the driver includes functions A, B, C and D, 
and could then program those functions directly into the virtual device driver. A 
system administrator may determine from a web site the I/O adapter device driver 
includes functions A, B, C and D, and could program a table that may be accessed 
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by the virtual device driver. A copy of the I/O device driver could be included in 
the guest system. There are countless different ways a virtual device driver could 
be programmed with or could receive functions of the I/O adapter device driver 
without querying the I/O adapter device driver. These simple examples above 
show conclusively that the examiner'-, assertion that Shmid somehow impliedly 
teaches the querying of the I/O adapter device driver to determine the available 
functions is incorrect. especially when this assumption goes against the other 
express teachings of Shmid as shown in detail above. 



In the Response to Arguments section of the pending office action, the examiner 
justifies the rejection by stating: 

As is clearly stated on col. 37, lines 21-30, the guest is capable of 
querying a device and its feature using the diagnose command. As clearly 
slated in col. 14, lines 1 1-65, devices are directly assigned to guests w ithin 
the system using the ATTACH command, either during the initiali/ation 
of the guest or by an administrator issuing the command at a command 
console. Therefore, a device that is directly assigned to a guest can be 
queried for its features, thereby meeting the claim limitation. 

The examiner assumes that when an I/O device in Shmid is directly assigned to guests 
within the system using the ATTACH command, the I/O device can then be queried for 
its features. This is not supported by the express language in Shmid, which explains in 
detail how an I/O operation by the guest system is processed. 



When an I/O operation or a special CPU function is requested by the guest 
system the SIE instruction is intercepted and ISX receives control to the 
point just after the SIE instruction. ISX recognizes the reason for the 
interception and performs the corresponding function. If an I/O operation 
is requested with a real I/O device, ISX requests the host operating system 
to execute it using its standard facilities. Shmid at col. 5 lines 42-49 

This language makes it very clear that when an I/O operation for a real I/O device is 
requested in the SIE instruction, ISX requests the host operating system to execute the 
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request using its standard facilities. This means the wall of separation between the guest 
system and host system is maintained. The fact that an I/O device is attached to a guest 
system does not mean the guest system may then communicate directly with the I/O 
device to query its available functions. The language quoted above from Shmid shows 
just the opposite is true: when the guest operating system or program requests an I/O 
operation with a real I/O device, the request is intercepted, and the host operating system 
is requested to execute the request using its standard facilities. This shows conclusively 
that no direct interaction between a virtual I/O adapter in the guest system and the I/O 
adapter device driver in the host system is possible. Nowhere does Shmid support the 
examiner's assumption that a virtual device driver in a guest system can query the I/O 
adapter device driver in the host system. 

For the many reasons given above claim 1 is allowable over Shmid, and 
applicants respectfully request reconsideration of the examiner's rejection of 
claim 1 under 35 U.S.C. § 103(a). 

Claims 6, 11. 19. 23. 27 and 34 

Independent claims 6, 1 1, 19, 23, 27 and 34 include limitations similar to those in 
claim 1 addressed above, and are therefore allowable for the same reasons. 
Reconsideration is respectfully requested. 

Claims 3, 8, 13, 16,21,25, 29, 31, 38 and41 

In the rejection of claim 3, the examiner provided no express mapping of any 
specific features of Shmid on the express limitations of claim 3. The examiner simply 
claims that the device to the guest system is controlled by the main operating system 
without indicating the relevance of these teachings to the limitations in claim 3. For this 
reason, the examiner has failed to establish a prima facie case of obviousness for these 
claims under 35 U.S.C. §103(a). 
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In addition, the examiner's assumptions are erroneous. Nowhere does Shmid 
teach or suggest "a transfer mechanism that transfers data between the virtual device 
driver and the shared network I/O adapter without the data passing through the I/O 
adapter device driver" as claimed in claim 3. 

In the rejection of claim 1, the examiner states Shmid teaches: 

(Dl) an I/O adapter device driver in the first logical partition, the I/O 
adapter device driver including a hardware interface to the shared network 
I/O adapter (citations omitted). All devices in a computer inherently 
require a device driver; therefore, the use of a network adapter, a device 
within the computer, meets this limitation. 

So by the examiner's own language in the rejection of claim 1, the examiner insists the 
use of a network adapter requires a device driver. If this is true, this undermines the 
examiner's rejection of claim 3. 

In the Response to Arguments section of the pending ol'lice action, the examiner 

I lardwarc devices are directly allocated to guest devices. Since the device 
driver executing on the guest is executing on a virtual machine, the driver 
constitutes a virtual device driver. Since the actual allocation step of the 
device to the guest system is controlled by the main operating system, the 
device is under the control of the main operating system. 

It is unclear how the examiner's language relates to the limitations in claim 3, because the 
examiner's own characterization of Shmid expressly teaches away from the limitations in 
claim 3. As discussed in detail above with respect to claim 3, any I/O request for a real 
device is handled by the host operating system "using its standard facilities." Col. 5 line 
49. The standard facilities in the host operating system include an I/O adapter device 
driver, as stated by the examiner in the rejection of claim 1 when the examiner stated: 
"All devices in a computer inherently require a device driver; therefore, the use of a 
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network adapter, a device within the computer, meets this limitation." This means 
according to the express teachings of Shmid, any request by a virtual device driver in a 
guest system must pass through the I/O adapter device driver in the host system. This is 
the prior art as shown in applicant's FIG. 3. Claim 3, in contrast, recites a transfer 
mechanism that transfers data between the virtual device driver in the second logical 
partition and the shared network I/O adapter in the first logical partition without the data 
passing through the I/O adapter device driver in the first logical partition, as shown in 
applicants' FIG. 5. Because an I/O request by a virtual device driver in a guest system is 
always handled "using standard facilities" in the host system, which includes by the 
examiner's own admission an I/O adapter device driver, all the data in Shmid necessarily 
passes from the virtual device driver, through the I/O adapter device driver, to the I/O 
adapter, as shown in applicant's FIG. 3. This expressly teaches away from "without the 
data passing through the I/O adapter device driver" as expressly recited in claim 3. 

Claims 8, 13, 16, 21, 25, 29, 31, 38 and 41 include limitations similar to those in 
claim 3 discussed above, and are therefore allowable for the same reasons. Applicants 
respectfully request reconsideration of the examiner's rejection of claims 3, 8, 13, 16, 21, 
25, 29, 31, 38 and 41 under 35 U.S.C. § 103(a). 

Claims 4-5, 9-10, 14-15, 22, 26, 30, and 39-40 

Each of claims 4-5, 9-10, 14-15, 17-18, 22, 26. 30, and 39-40 depend on an 
independent claim that is allowable for the reasons given above. As a result, all of claims 
4-5, 9-10, 14-15, 22, 26, 30, and 39-40 are allowable as depending on allowable 
independent claims. 
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Conclusion 



In summary, none of the cited prior art, either alone or in combination, teach, 
support, or suggest the unique combination of features in applicants' claims presently on 
file. Therefore, applicants respectfully assert that all of applicants' claims are allowable. 
Such allowance at an early date is respectfully requested. The Examiner is invited to 
telephone the undersigned if this would in any way advance the prosecution of this case. 



MARTIN & ASSOCIATES, L.L.C. Respectfully submitted, 

P.O. Box 548 

Carthage, MO 64836-0548 

(417) 358-4700 By /derekpmartin/ 

Derek P. Martin 
Reg. No. 36,595 
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